\section{Введение}

\subsection{Смысл ядра}

Нет никаого смысла клонировать линукс или Windows. Хотя с одной стороны смысл
ReactOS понятен - сделать возможность любителям Windows почувствовать себя
свободными. Но проблема в том, что они всеравно никогда не догонят Windows.
Windows умрет и все про него успеют забыть раньше, чем ReactOS сможет хотя бы
приближённо его догнать.

Но о чем это я? Ах да, зачем нужно еще одно ядро? Нет смысла клонировать что-то
имеющееся, но всегда есть смысл попробовать сделать что-то, чего до этого еще
никто не делал. Может быть это что-то найдет свое место под солнцем.

Кроме того ничего не мешает использовать существующие открытые решения. Ведь что
POSIX, что WinAPI - это всего лишь программные библиотеки. Вовсе не обязательно
ставить их во главу системы. Они могут мирно сосуществовать, но где нибудь в
стороне от основной системной парадигмы.

А основную парадигму стоит выбирать так, чтобы это соответствовало требованиям
современной реальности. А современная реальность указывает нам направление на
многоядерность и децентрализованность.

Бытует мнение, что рост количества ядер не может обеспечить соответствующего
роста производительности системы. Но помоему это не совсем так. Естественно,
узкие места всегда найдутся, но прежние системы состояли из весьма крупных
модулей, соответственно задача распаралеливания не могла решаться в достаточной
степени эффективно.

В моей системе модули будут весьма мелкими, что с одной стороны накладывает
дополнительные расходы на взаимодействие, но с другой стороны позволяет
эффективнее использовать имеющиеся мощности. Кроме того само взаимодействие
организовано таким образом, что для приложения не будет иметь значения
расположение абонента. Что даст больш\'{у}ю гибкость в создании распределенных
решений.

\subsection{Основные идеи ядра}

Ядро MDF - это практически традиционное микроядро. Интерфейс ядра отличается
высокой универсальностью по отношению к ядерным сущностям и ограничивается
восемью функциями\footnote{Интерфейс ядра minix3 насчитывает порядка 30 функций,
про другие ядра сходу не скажу}. Поскольку функции универсальны, ими не слишком
удобно пользоваться в программах. Для облегчения процесса программирования будет
предусмотрена библиотека\footnote{libSystem может быть?}, Которая сконцентрирует
в себе многочисленные функции MDF не относящиеся к libc или POSIX\footnote{Хотел
написать про идею системы а пишу про ерунду про какую-то\ldots}.

Сущности ядра именуются ресурсами, которые бывают нескольких типов - процессы,
нити, точки вызовов, память и пользовательские\footnote{Что, и это все??? Ну
порты я перенесу в память, прерывания я перенесу в кастомы, а так действительно
все}.

Основным средством взаимодействия в MDF являются межпроцессные вызовы (Trans
Process Call, TPC). Весьма медленный, но удобный и максимально универсальный
механизм, отдаленно напоминающий RPC. TPC обеспечивает передачу бинарных
неструктурированных данных ограниченного объема\footnote{Но надо сказать, что
ограничение на объем будет велико. может быть несколько десятков мегабайт, хотя
не знаю кому может понадобиться так много данных.} удаленному
\footnote{Неизвестно насколько далеко.} получателю. TPC работает по схеме
запрос/ответ. Для передачи данных используется единственный буфер обмена. Размер
буфера определяется вызывающей стороной\footnote{Не за чем здесь столько
конкретики, впереди еще целая книга}.

\subsection{Запуск ядра}

При запуске ядра ему передается некоторый список параметров. Параметры зависят
от архитектуры, возможно присутствие или отсутствие некоторых функций
\footnote{Будет управляться конфигурацией ядра.}.

\subsubsection{Настройки консоли}

Параметр console может иметь значения vga, mda, serial. При этом существенно то,
что функциональность экрана смерти зависит от возможностей консоли. Хотя
интерактивность должна присутствовать всегда. Варьироваться будет вид экрана
смерти, от минимальной информации до полноэкранного дампа.

Кстати не стоит исключать и отсутствие консоли ядра вообще (console=none), Это
позволит существенно экономить на объеме ядра\footnote{В том случае, если
консоли отключены при компиляции. Хотя в этом случае ядро и так будет молчать.}.


% Перенес из API, там этому не место. но часть из этого материала возможно
% переместиться в Stub-Types
% \subsubsection{Основный понятия}
%
% \subsubsection{Типы}
%
% Поскольку API у нас сишное, типы, используемые при написании API будут во
% многом походить на стандартные типы си.
%
% \begin{description}
% \item[size\_t] Стандартное.
% \item[timeout\_t] Это исключительно микросекунды. не знаю как лучше обозвать тип
% \item[id\_t] Идентификатор ресурса... не нравится мне слово handle сил нету.
% \item[laddr\_t] Линейный адрес.
% \item[paddr\_t] Физический адрес. иногда бывает нужен.
% \end{description}\par
%
% \subsubsection{Ресурсы}
%
% Весь интерфейс ядра построен на ресурсах. Идентификатор ресурса - это целое
% ненулевое беззнаковое значение в диапазоне, определяемом платформой.
%
% Нулевой идентификатор - служебный. Он интерпретируется, в зависимости от
% ситуации, как идентификатор нити, как идентификатор процесса, как пустой
% идентификатор\footnote{Идентификатор, не ссылающийся не на какой ресурс}.
%
% \subsubsection{Нити}
%
% Нить - это основная исполняемая сущность системы. Каждая нить обладает
% приоритетом, который влияет на частоту выделения ей квантов времени процессора.
%
% Каждая нить имеет стек и каталог страниц\footnote{Это конечно тонкость
% реализации, нужно ли здесь об этом писать?}.
%
% Нити хранятся в списках планировщика. Списков будет три - список активных,
% список пассивных и список спящих.
%
% \subsubsection{Процессы}
%
% Процесс это абстракция. Можно ассоциировать процесс с запущенным бинарем, но
% по большому счету это только обобщающая сущность для выполняющихся нитей. А
% так же основной субъект безопасности системы.
%
% Процесс хранит ссылки на используемые ресурсы. Эти ссылки одновременно
% являются способностями, которые ограничивают возможности процесса по
% использованию соответствующего ресурса.
%
% Процесс так же имеет ссылку на самого себя. Это позволяет ему прекращать свое
% существование или менять свои параметры.
%
% Процесс владеет регионами памяти.
%
% \subsubsection{Точки вызовов}
%
